Database consolidation involves distributing and sharing computing resources among multiple databases managed by one or more database servers of database management systems (DBMS). Databases may be consolidated using a container DBMS. A multitenant container database (CDB) includes one or more pluggable databases (PDBs). In a container DBMS, each pluggable database may be open or closed in the container database independently from other pluggable databases.
Pluggable databases may be “plugged in” to a container database, and may be transported between database servers and/or DBMSs. The container DBMS may manage multiple pluggable databases and a given database server instance may serve those pluggable databases from the container database. As such, a given container database allows multiple pluggable databases to run on the same database server and/or database server instance, allowing the computing resources of a single database server or instance to be shared between multiple pluggable databases.
An application may access a pluggable database by establishing a database session on the container DBMS for that pluggable database, where a database session represents the connection between an application and the container DBMS for accessing the pluggable database. A database session is initiated for a pluggable database by, for example, transmitting a request for a new connection to the container DBMS, the request specifying the pluggable database. A container DBMS may host multiple database sessions, each database session being for one of multiple pluggable databases.
One of the big advantages of container database architecture is the ability to provision new databases quickly. However, in order to clone a particular source PDB, the source PDB generally needs to be in read-only mode. In read-only mode, write operations are prohibited and, as such, the work that can be performed on the source PDB in read-only mode is severely limited. Thus, the requirement for a source PDB to be in read-only mode throughout the potentially significant duration of a cloning operation can generate similarly significant downtime for the source PDB. For example, copying files for a terabyte-sized PDB over a network can take days, during which no write operations may be performed on the source PDB that is required to be in read-only mode for the cloning operation.
One way to clone a PDB is by using third party tools. However, since third-party tools are not native to the database, such tools do not have access to many optimizations that are available natively in many databases. Furthermore, it takes effort for database administrators to configure third-party tools to enable them to work with (and clone) data from a given CDB. As such, working with third-party tools to perform cloning operations on PDBs significantly increases the database provisioning costs and slows down application development that requires PDB cloning.
Moving a PDB between container databases presents many of the same problems as cloning a PDB. For example, moving the data for a PDB from a source CDB to a destination CDB can take a significant amount of time (i.e., on the order of days for very large PDBs). It is also costly to make a PDB unavailable for the duration of moving the PDB. Also, relocating a PDB to a destination CDB can be disruptive to users that use data from the PDB at the source CDB.
Generally, moving the files for a PDB between container DBMSs may be accomplished in multiple ways, including: copying the files to an external hard drive and physically moving the hard drive to the location of the destination storage, setting up an auxiliary DBMS that leverages replication to synchronize changes across container databases, and live migration of virtual machines from one physical server to another.
The architecture of a container DBMS greatly facilitates transporting databases between database servers and/or DBMSs. Tablespace files and a data dictionary store may be moved between environments of container DBMSs using readily available mechanisms for copying and moving files. The tablespace files, along with supporting files, are referred to herein collectively as a transportable database package. However, a transportable database package is a logical set of loose files, which may be difficult to identify and manage.
Once the transportable database package of a pluggable database is moved to the environment of the target container DBMS, the pluggable database can be plugged into the target container DBMS. In an embodiment, plugging in the pluggable database is performed in response to receiving a DDL command to plug in the pluggable database, the DDL command also identifying the transportable database package. In response to receiving the DDL command, the container DBMS plugs in the pluggable database. Plugging in the pluggable database entails such operations as updating a root database dictionary to define the pluggable database, such updates including, for example, adding a record to a metadata table. Error checking is also performed. For example, checks are performed to ensure that the name of the pluggable database is unique within the container DBMS and that tablespace files are not already being used for other tablespaces in the container DBMS.
A container DBMS provides advantages for database consolidation. Among such advantages is providing a high degree of isolation concurrently along with a high degree of resource sharing. Multiple pluggable databases may run on the same database server and/or database server instance, allowing the computing resources of a single database server or instance to be shared between multiple pluggable databases.
Another important advantage is fast provisioning of databases. A transportable database package of a source pluggable database may be copied to quickly create a new target pluggable database as a clone of the source pluggable database. The provisioning of a pluggable database is primarily bounded by the time required to copy files of the transportable database package and to process one or more DDL commands that require relatively little updating of metadata or other type of processing.
However, copying and moving pluggable databases may introduce complexity. For example, the infrastructural fabric of a data grid may be a diverse ecosystem with many container databases.
Not all container databases may be compatible with a given pluggable database. For example, two different pluggable databases may share compatibility with all, some, or none of the same container databases.
Furthermore, container databases readily accept installations of pluggable databases, which encourages distributed deployment, replication, horizontal scaling, and bulk deployment throughout a cluster. As such, instances of a pluggable database may benefit from a capability to be mass produced.